Сколько тестировщиков нужно, чтобы выловить все баги на проекте масштаба enterprise? Однозначного ответа никто не даёт. Одни источники считают нормальным соотношение «один тестировщик на 10 разработчиков», другие говорят, что «1:1 — в самый раз» (и то мало).
В рамках методологии Agile, которой придерживаемся мы в kt.team, тестировщиков как отдельной позиции не нужно вообще. Рассказываем, как мы живём и работаем без них и почему отсутствие тестировщика — это благо как для заказчика, так и для разработчика.
Куда они делись?
Внимательно просмотрев штат kt.team, ты не найдёшь у нас ни одного «кликера» или тестировщика по автотестам. Это вовсе не значит, что мы скрываем часть своих сотрудников или отдаём тестирование на аутсорс. Мы действительно отказались от тестировщиков, оставив в штате двоих QA-инженеров. В рамках SCRUM-подхода такая структура не просто имеет право на жизнь — она позволяет выдавать качественный результат.
Так было не всегда.
Как и большинство коллег, мы исповедовали конвейерный подход. Раньше у нас в продуктовой команде тоже были и проджекты, и разработчики, и тестировщики… В общем, все необходимые позиции, которые закрывали этапы разработки проекта.
Но примерно два года назад мы начали переходить на методологию Agile и, в частности, на SCRUM в управлении проектами. Стали постепенно вводить технику test-driven development (TDD). Сейчас мы уже можем подбить статистику и официально заявляем: качество кода от этого не пострадало.
Сложный проект — это всегда запутанный класс систем (об этом мы говорили в одной из предыдущих статей). Давай рассмотрим, как строится работа над ним на «конвейере» и по методологии Agile с точки зрения места разработчика.
Винтик на большом «конвейере»
Работа над сложным проектом при конвейерном подходе выглядит примерно так.
1. Заказчик ставит высокоуровневые задачи на продукт или решение.
2. Менеджер проекта их обрабатывает и следит за «конвейером».
3. Бизнес-аналитики и системные аналитики перерабатывают требования, пишут кучу документации.
4. Тимлид определяет на базе разработанных требований, кто и что будет разрабатывать.
Дальше понятно. Разработчики пишут код. Тестировщики проверяют разработанное на предмет соответствия задачам и проектной документации. Системные администраторы обеспечивают инфраструктуру.
Многие разработчики и наследники «советской школы» считают этот процесс эталонным.
Кажется, проблем в этой системе быть не должно. Но на деле всё не так просто.
Разработчик не в курсе целей проекта, с позиции «конвейера» ему это «не нужно»: он всё равно не может повлиять на них. Он не развивает компетенции по пониманию бизнес-результата, по обеспечению качества. Он не чувствует ответственности за конечный результат.
Единственная задача разработчика — писать свои задачи.
Как они связаны с конечным результатом, с целью проекта, как влияют на работу других разработчиков, почему работа строится именно так, он не понимает: это зона ответственности тимлида и проджекта. Всё, что нужно от разработчика, — «красота кода».
Разработчик тут — вариация машинистки. Ему дают хорошо сформулированную и описанную задачу — он «переводит» её на свой язык программирования (PHP, Go, Python — неважно).
Причём неважно, идёт ли речь о джунах или о разработчиках высокой квалификации: на «конвейере» они могут выполнять только свою узкоспециализированную задачу и ничего больше.
Бонус: место тестировщика на «конвейере»
В конвейерном подходе тестировщик всегда остаётся внешним человеком, который не погружается в проект или фичу полностью. Код попадает к нему в руки уже в готовом виде и чаще всего — с минимальными пояснениями: почему фича была реализована именно так и зачем такое решение в целом нужно.
Для «прокликивания» и прогона по автотестам, по большому счёту, вникать в ситуацию и не надо. Чистейшей воды monkey business, механическая работа. Не зря фиктивная компания Primate Programming Inc., «предлагавшая» в своё время услуги тестировщиков-шимпанзе, у многих не вызвала сомнений.
Впрочем, вернёмся к тестировщикам. Не вникая в ситуацию, они не смогут раскопать проблемы в нестандартных сценариях, достаточности или недостаточности какого-либо решения. Просто потому что ни знать, ни думать о них они не будут.
Agile: когда есть цель
В Agile другой подход к задачам. Плоская команда, состоящая (у нас например) из SCRUM-мастера, проджект-менеджера и разработчиков, в которой все, кроме наставника (SCRUM-мастера), занимаются доставкой ценностей проекта. Тестированием также занимается вся команда: разработчики пишут тесты на коды друг друга (кросс-тестирование).
Означает ли это, что разработчики занимаются низкоквалифицированным трудом? Категорически нет. Во-первых, один разработчик не на словах на стендапе, а действительно просматривает, что сделано другими. Его задача — не столько найти изъян, сколько ознакомиться с результатом работы другого человека в проекте.
Люди, находящиеся в контексте всего проекта, принимают лучшие решения, больше осведомлены о бизнес-целях и результатах. Команда включена в проект полностью, принимает более осознанные решения, лучше понимает связь своей работы с результатом.
Пара слов о потерянном времени
К тестировщикам, как правило, отношение двоякое. С одной стороны, их принято считать не-совсем-разработчиками, которым не хватило навыков и умений на карьеру полноценного инженера. С другой — именно их назначают крайними, если что-то идёт не так. Негласно, неофициально и не всегда — но такая тенденция есть.
И это самым фатальным образом сказывается как на динамике внутри команды, так и на профессиональных качествах каждого из разработчиков.
Привычка к тому, что кто-то «подтирает» ошибки, расхолаживает. Не выловил проблемы сам? Ничего, придёт тестировщик и найдёт всё, что только можно найти.
Отсюда следует ещё кое-что. Задумывался когда-нибудь, сколько времени разработчика «сжирает» взаимодействие с тестировщиком? Очень много, иногда — до трети!
Как это получается?
Готовый написанный разработчиком код тестируется не сразу: он ждёт, когда наступит его очередь в графике тестировщика (время). Тестировщик прогоняет код по тестам исходя из ТЗ и обнаруживает баги, недочёты, проблемы (ещё время).
Задача возвращается к разработчику. Но: он не сидел и не ждал, когда это произойдёт. Он погрузился в совсем другие задачи. Чтобы устранить недочёты, он должен выдёргивать себя из рабочего процесса, перенастраиваться, заново вникать в проблему. А это — время (снова!), силы и нервы.
После исправлений код опять возвращается на тестирование, и процесс повторяется снова «до победного».
В итоге разработчик постоянно переключается туда-сюда между задачами и не может нормально погрузиться в решение проблем.
Спрашивается, а как же многозадачность? А многозадачность убивает когнитивный навык глубокого погружения в проблему и приводит к неспособности фокусироваться.
Качество без тестировщиков — это не миф
В Agile вопросы качества кода решаются не только кросс-тестированием, о котором мы говорили выше. Есть множество практик, в том числе TDD, Agile-тестирование, роль SCRUM-мастера в процессе. Обо всём этом мы расскажем в следующих статьях.
Генеральный директор kt.team
«Строго говоря, разработчики у нас не кодеры, а инженеры. Их уровень таков, что они объективно могут проверить свою работу и работу коллег при кросс-тестировании. И даже те, кто приходит к нам из других парадигм, перестраиваются под нашу систему работы относительно быстро.
Тестировщик в Agile-команде фактически не нужен, только наставник по качеству — QA-инженер. Тот, кто будет регулярно смотреть на проект и давать оценку прошедшим мероприятиям: наличие тестов, скорость работы, наличие инцидентов и их тип. Он способен посмотреть на задачу новым взглядом, провести аудит. И не просто выявить проблемные места, а взять на себя функцию наставника и предложить решение.
QA-инженер сотрудничает со всеми проектными командами. Он знает, как каждая из них решает возникающие проблемы, и может распространить успешную практику на другие команды и проекты».
Вывод
С бизнесом мы работаем давно и плотно. И знаем одну простую вещь: заказчику неважно количество тестировщиков. И даже тест-кейсы сами по себе ему неважны. Он хочет, чтобы мы обеспечили работающее решение его бизнес-задач. Качественное, гибкое, прозрачное и лучше — в самые короткие сроки.
Agile всё это обеспечивает. Когда разработчик видит конечную цель и выдаёт осознанные решения, а не «перевод ТЗ на язык программирования», не тратит время на бесконечные итерации с тестированием через третьи руки, удаётся добиться поставленных целей гораздо быстрее.
И, что не менее важно, гораздо быстрее происходит личный и профессиональный рост самого разработчика. Потому что осознанное решение задач помогает не только развивать использование языков программирования и наращивать стек, но и приобретать навыки проектирования, управления, понимания бизнеса и лучше понимать другие части своего проекта.
